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REMARKS 

Claims 23-42 are all the claims pending in the present application. In summary, the 
Examiner previously maintained the following prior art rejections. Specifically, claims 23-25, 
27-28, 31-34, 36-37 and 40-42 were previously rejected under 35 U.S.C. § 103(a) as allegedly 
being unpatentable over Kitamura (Domain Name Auto-Registration for Plugged-in IPv6 Nodes, 
http://tools.ietf.org/html/draft-ietf-dnsext- ipv6-name-auto-reg-Q0.txt . dated 12/02/2002) in view 
of Borella (US 2003/0229697). Claims 26 and 35 were previously rejected under 35 U.S.C. § 
103(a) as allegedly being unpatentable over Kitamura in view of Borella and further in view of 
Thomson et al (IPv6 Stateless Address Autoconfiguration, http://www.ietf.org/rfc/rfc2462.txt 
dated December 1998, hereafter Thomson). Finally, claims 29-30 and 38-39 were previously 
rejected under 35 U.S.C. § 103(a) as allegedly being unpatentable over Kitamura in view of 
Borella and further in view of Narten et al (Neighbor Discovery for IP Version 6 (IPv6), RFC 
246 1. http://www.ietf.org/rfc/rfc246 1 .txt . dated 12/1998, hereafter Narten). 

Applicants submit that the claimed invention is patentably distinguishable over the 
applied art at least based on the following new arguments in support of patentability. 
The pages 6-7 of Kitamura, "3. 2 Detector Function" are the follows. 
3.2 Detector Function 

The role of a "Detector" is to detect appearances of new plugged-in 
IPv6 nodes and to send the detected information to a "Registrar" 
without applying any selection rules to it. 

Detectors are NOT required to perform any "intelligent" operations. 

A Detector knows the location of its corresponding Registrar. (This 
location is configured manually.) Detected information must be sent 
securely from the Detector to the Registrar by using some kind of 
secure communication method (e.g., [TSIG] -like authentication, iPsec 
(AH, ESP) , [TLS] ) . 
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Since a Detector must be placed where appearances of new plugged- tn 
xpve nodes can be detected, the Detector location is restricted. 

In typical cases, appearances are detected by watching for DAD 
packets that are issued from plugged-in IPv6 nodes (see section 3.4) 
So, the Detector must be placed where it can listen to link-local 

eacriiS^rach^evrSe mechanism" 0 ^ ** DfttSPt ° r must b * ? Iaced on 

The Detector function can be implemented on routers, because its 
operations are simple and lightweight and routers are located at 
suitable places for listening to link- local scope multicast packets 
that are issued from plugged-in IPv6 nodes. • 

In order to identify Detectors, each Detector must have its own 
^ te f!° r ID - Since a Detector is placed on each link, the Detector's 
IP. address that is connected to its watching link can be used for the 
Detector ID. (Default Address Selection for IPv6 [DEF-ADDRJ algorithm 
is also applied here.) When a Detector sends detected information to 
a Registrar, the Detector ID is attached to it. 

In order to meet "temporary address" [RFC304I] issues (see section 
5), a link-layer address of a detected IP address is also attached to 
detected information. 

As such, Kitamura discloses "A detector knows the location of its corresponding 
registrar." From this disclosure, Applicants submit that a detector and its corresponding registrar 
are separated from each other. Therefore, a detector and its corresponding registrar cannot be 
placed inside one device, for example, a DNS server. 

Also, Kitamura discloses "Since a detector must be placed where appearances of new 
plugged-in IPv6 nodes can be detected, the detector location is restricted. In other words, a 
detector must be placed on each link to achieve the mechanism." Referring to the following 
figure 2 of Kitamura, a DNS server is not placed on each link. Therefore, Applicants submit that 
Kitamura excludes the possibility that a detector can be placed inside the DNS server. 
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Fig. 2 Multiple-Link Case Example 



Entry and consideration of these Remarks are respectfully requested. 
Request for Interview 

Also, as indicated in the previously submitted Request for Interview, Applicants 
respectfully request that the Examiner contact the undersigned to further discuss this cas 
substantive examination and issuance of new Office Action. 

Respectfully submitted, 



SUGHRUE MION, PLLC 
Telephone: (202) 293-7060 
Facsimile: (202) 293-7860 




Registration No. 52,778 



WASHINGTON OFFICE 



23373 



CUSTOMER NUMBER 



Date: July 3, 2008 
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